This PR:

• simplifies setvar evaluation code, reusing the same variable expansion for both + and - operations.
• Fixes a bug that was not allowing to initialize a variable with a negative number.
  • setvar:TX.score=+5: even if TX.score does not exist, it defaults to 0 and the variable is initialized to 5.
  • setvar:TX.score=-5: was failing. Now, the behavior is aligned. Even if TX.score does not exist, it defaults to 0 and the variable is initialized to -5.
• Adds a warning when a macro is expanded but the variable is not found in the collection. It notably happens in CRS strconv.Atoi: parsing tx.blocking_outbound_anomaly_score: invalid syntax #888. When variables are used before being initialized (E.g. becuase of a misconfiguration), the macro expansion returns the name of the variable itself. It might lead to subsequent errors (E.g. trying to perform arithmetical operations). This warning should help to understand more clearly the problem.
• Notably, running ftw with the just added warning I found out that that code was reached for a total of 1265 times. It happens because LogData action Evaluate performs the macro expansion ahead of time (when iterating over all the not disruptive actions) and stores the result in the (to my eyes) unused tx.LogData variable. This PR proposes to:
  • make the LogData action Evaluate a no op. The expansion is already performed after all the other actions (and therefore after the expected variable has been populated).
  • deprecate the usage of tx.LogData. As far as I can see it was populated only there, and never used. LogData expanded values are indeed stored inside the MatchData struct and saved inside the transaction in tx.matchVariable. If the reasoning is correct, it should also lead to tiny performance improvements, avoiding useless macro expansion attempts. A double-check about it would be very welcome.

Closes #888